Autonomous mapping of protected data streams to Fibre channel frames

ABSTRACT

A hardware-based offload engine is disclosed for mapping protected data into frames. For a write operation, the HBA determines host addresses and the size of data to be read from those addresses. The HBA also determines the frame size and protection scheme for data to be written. A frame transmit engine reads each host descriptor in the host data descriptor list to determine the location and byte count of the data to be read. A DMA engine reads the protection information/scratch area to determine the exact data size used to fill each frame and the protection scheme, and retrieves one or more free frame buffers. Check bytes are inserted alongside the data and stored in free frame buffers. After each frame is filled, the frame transmit engine also generates and stores header information for that frame, and then combines header, data and check bytes for transmission over the network.

FIELD OF THE INVENTION

This invention relates to the transmission of data between a host and atarget, and more particularly to a hardware-based offload engine forgenerating data protection information and mapping protected data intoframes in a manner that minimizes the involvement of a local processor.

BACKGROUND OF THE INVENTION

When a host application requests the transmission of Fibre Channel (FC)frames to move data from host memory to a storage system, manypreparation steps are needed before the frames can be transmitted over aFC link. It is up to lower levels of abstraction, namely the hardware oronboard firmware of a host bus adapter (HBA) or input/output controller(IOC) to segment the host data into units that are consistent with FCframes and to also insert/delete/pass any necessary protectioninformation into the stream of data. When data is moved from host memoryand is protected by protection information, there is a contraction orexpansion of the actual data length that must be taken into account whenmapping the host data to FC frames.

In previous generations of products, the tasks outlined above werecarried out mainly by an integrated processor in the HBA. With theincreasing use of protection information such as the T10 protectioninformation standard in data transmission, these tasks and calculationshave become increasingly complex and taxing on the processor. As FC linkspeeds increase, link rates are outpacing the processing power/clockspeeds of processors that can be integrated into a microchip.

FIG. 1 illustrates an exemplary conventional system 100 for transferringdata between a host computer and targets over a communications network.In FIG. 1, a host computer 102 is capable of sending or receiving datato and from targets 104 connected over a communications network 106 suchas a Storage Area Network (SAN). Communications link 108, which enablescommunications between the host computer 102 and the targets 104, mayoperate under any one of the known networking protocols such as FC.

The host computer 102 typically includes a host processor 110, hostmemory 112 for storing application data 114, and a driver 116 forcommunicating with an IOC or an HBA 118 using a computer system bus 120such as Peripheral Component Interconnect Express (PCIe). The HBA 118provides connectivity between the host computer 102 and the targets 104,and typically includes firmware 134 and a local processor 122 such as anAdvanced RISC Machines (ARM) processor. In addition, the HBA 118 mayalso include a Direct Memory Access (DMA) engine 124 and local memory126. The DMA engine 124 may include hardware operating under the controlof the local processor 122, and serves to offload the host processor 110by performing data transfers to and from the host memory 112 withminimal intervention from the host processor. For example, data to betransferred from the host memory 112 to a target 104 may be formattedand placed in local memory 126 by the DMA engine 124 for subsequenttransfer to a target. For frame-based communication links 108, the data(which is not typically arranged in frame-sized blocks) may be formattedinto frames using firmware 134 executed by local processor 122 andstored in local memory 126 prior to being transmitted over the link asframes of data 128. The local memory 126 may be organized intocontiguous frame-sized blocks for storing frames of data.

In the conventional system of FIG. 1, the local processor 122 had tokeep track of the boundaries between frames while formatting the datainto frames and storing it into frame-sized blocks. Another engine (notshown in FIG. 1) may be responsible for performing data transfersbetween the local memory 126 and devices connected over thecommunications link 108.

The system of FIG. 1, with local processor 122 involvement in the datatransfer process, works well for data rates of up to about 4 Gigabitsper second (Gbit/sec). However, state of the art networks can operate atspeeds of up to 8 Gbit/sec or more, which can be too fast for the localprocessor 122.

In addition, the T10 protection information standard, the contents ofwhich are incorporated herein by reference, now requires that additionalcheck bytes or data integrity fields (DIFs) 130 be inserted into thedata to provide end-to-end data protection and verification. Each checkbyte 130 may be associated with a certain number of bytes of real data132, which may correspond to sectors in the disks that store the data.The check bytes 130 are a function of the data they protect, but can bestripped off, passed or inserted after transmission, and stored alongwith the real data. The size of the protection data 130 (e.g. eightbytes for T10) and real data 132 being protected is configurable, as isthe alignment of the protection data 130 within a frame. Therefore, inthe context of a write command, these check bytes or protection data 130must be computed, mapped and inserted into different places within thereal data 132 of a frame in accordance with the type of disks in thetarget that will be storing the data, which may change from frame toframe. In the system of FIG. 1, the T10 protection standard requiresthat the local processor 122 control the identification of the type ofdata protection, what data to read from host memory 112 in view of thetype of data protection, and where the check bytes are to be placed inthe local memory 126 along with the actual data. However, the localprocessor 122 may not be able to perform these control functions alongwith formatting the data into frames and keep pace with the speedrequirements (link rates) of state of the art networks.

Therefore, there is a need for mapping protected data into frames in amanner that minimizes the involvement of a local processor in a HBA orIOC.

SUMMARY OF THE INVENTION

Embodiments of the invention are directed to a hardware-based offloadengine for mapping protected data into frames in a manner that minimizesthe involvement of a local processor in a HBA or IOC by implementingmapping control in hardware and memory. By offloading the localprocessor from having to perform the tasks needed to process outgoingtraffic, and raising the level of abstraction at which the processoroperates for outbound data streams, the mapping of protected data intoframes can be performed at speeds that allow for data rates of 8Gbits/sec or more to be achieved. In addition, this significantly freesthe processor to perform other tasks.

When an application running on the host computer sends a command to theHBA indicating that a read or write operation on host data is requested,firmware in the HBA determines from the host computer the host addressesat which the data resides (or will reside) and the size of the data tobe read from or written to those addresses (a byte count), and storesthis host descriptor information into a host data descriptor list inrandom access memory (RAM) in the HBA. For each host descriptor list,the firmware also determines the frame size and the protection schemefor the data to be read or written, and stores this information in aprotection information/scratch area in RAM in the HBA.

In the case of a write operation, a frame transmit engine is theninitiated by the firmware to perform the autonomous mapping of protecteddata into frames. The frame transmit engine reads each host descriptorin the host data descriptor list, one at a time, to determine thelocation and byte count of the data to be read, then issues the locationand byte count descriptor to the DMA engine. The DMA engine reads theprotection information/scratch area to determine the exact data sizeused to fill each frame and the protection scheme for that data,determines one or more free frame buffers from a transmit free bufferpool, and automatically retrieves buffer from the free buffer pool. Thecheck bytes are checked and passed, or checked and striped, or insertedin the the appropriate places alongside the data, and stored into thefree frame buffers. After each frame is filled by the DMA engine, theframe transmit engine also generates and stores the header informationfor that frame into a separate area of local memory, and then combinesthe header, data and check bytes for transmission over the network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary conventional system for transferringdata between a host computer and targets over a communications network.

FIG. 2 illustrates an exemplary system for transferring data between ahost computer and targets over a communications network according toembodiments of the invention.

FIG. 3 illustrates an exemplary frame transmit engine according toembodiments of the invention.

FIG. 4 illustrates another exemplary representation of a host computeraccording to embodiments of the invention.

FIG. 5 illustrates an exemplary expansion/contraction adjustment blockaccording to embodiments of the invention.

FIG. 6 illustrates an exemplary block diagram of the DIFexpansion/contraction and frame segmentation functions according toembodiments of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description of preferred embodiments, reference is madeto the accompanying drawings which form a part hereof, and in which itis shown by way of illustration specific embodiments in which theinvention may be practiced. It is to be understood that otherembodiments may be utilized and structural changes may be made withoutdeparting from the scope of the preferred embodiments of the presentinvention.

Embodiments of the invention are directed to a hardware-based offloadengine for mapping protected data into frames in a manner that minimizesthe involvement of a local processor in a HBA or IOC by implementingmapping control in hardware and memory. By offloading the localprocessor from having to perform the tasks needed to process outgoingtraffic, and raising the level of abstraction at which the processoroperates for outbound data streams, the mapping of protected data intoframes can be performed at speeds that allow for data rates of 8Gbits/sec or more to be achieved. In addition, this significantly freesthe processor to perform other tasks.

When an application running on the host computer sends a command to theHBA indicating that a read or write operation on host data is requested,firmware in the HBA determines from the host computer the host addressesat which the data resides (or will reside) and the size of the data tobe read from or written to those addresses (a byte count), and storesthis host descriptor information into a host data descriptor list inrandom access memory (RAM) in the HBA. For each host descriptor list,the firmware also determines the frame size and the protection schemefor the data to be read or written, and stores this information in aprotection information/scratch area in RAM in the HBA.

In the case of a write operation, a frame transmit engine is theninitiated by the firmware to perform the autonomous mapping of protecteddata into frames. The frame transmit engine reads each host descriptorin the host data descriptor list, one at a time, to determine thelocation and byte count of the data to be read, then issues the locationand byte count descriptor to the DMA engine 224. The DMA engine 224reads the protection information/scratch area to determine the exactdata size used to fill each frame and the protection scheme for thatdata, determines one or more free frame buffers from a transmit freebuffer pool, and automatically retrieves buffer from the free bufferpool. The check bytes are checked and passed, or checked and striped, orinserted in the the appropriate places alongside the data, and storedinto the free frame buffers. After each frame is filled by the DMAengine 224, the frame transmit engine also generates and stores theheader information for that frame into a separate area of local memory,and then combines the header, data and check bytes for transmission overthe network.

Although some embodiments of this invention may be described herein interms of FC frames being transmitted over a FC link in a storage areanetwork (SAN), it should be understood that embodiments of thisinvention are not so limited, but are generally applicable to anyframe-based networked communications protocol, such as 10 GB Ethernet.In addition, although some embodiments of this invention may bedescribed herein in which the HBA is an initiator, it should beunderstood that embodiments of this invention are not so limited, butare also generally applicable to systems in which the HBA is a target orintermediate device such as a redundant array of independent disks(RAID) controller.

FIG. 2 illustrates an exemplary system 200 for transferring data betweena host computer and targets over a communications network according toembodiments. of the invention. In FIG. 2, a host computer 202 is capableof sending or receiving data to and from targets 204 connected over acommunications network 206 such as a SAN. The communications link 208that enables communications between the host computer 202 and thetargets 204 may operate under any frame-based networking protocol suchas FC.

The host computer 202 typically includes a host processor 210, hostmemory 212 for storing application data 214, and a driver 216 forcommunicating with an IOC or an HBA 218 using a computer system bus 220such as PCIe. The HBA 218 provides connectivity between the hostcomputer 202 and the targets 204, and typically includes firmware 234and a local processor 222 such as an ARM processor. In addition, the HBA218 may also include one or more frame transmit engines 236, a DMAengine 224, and local memory 226.

In embodiments of the invention, one or more frame transmit engines 236are coupled between the local processor 222 and the DMA engine 224. Eachframe transmit engine 236 is associated with a particular sequence offrames to be sent to or received from a particular target 204, may becomprised of hardware, and may offload the local processor 222 byperforming functions in hardware that would otherwise have to beperformed by the local processor, such as identification of the type ofdata protection for a particular sequence of frames, identifying thedata to read from host memory 212 in view of the type of dataprotection, and where the check bytes are to be placed in the localmemory 226 along with the actual data.

A separate host data descriptor list 238 may be utilized by each frametransmit engine 236 to determine the host addresses and byte count ofapplication data to be read from, or written to, host memory 212. Thehost data descriptor lists 238 may be stored in RAM in the HBA 218. Eachhost data descriptor list 238 is associated with a particular sequenceof frames to be sent to or received from a particular target 204, andmay contain a plurality of entries or host descriptors 246, each entryassociated with a unique host address and byte count for data to be readfrom or written to host memory 212. The host data descriptor lists 238may be programmed by the local processor 222 when a read or writerequest is received. The host addresses and byte count information arepassed from the application 214 to the driver 216 and then to the localprocessor 222, which then writes the information into the appropriatehost data descriptor list 238. Note that the frame transmit engines 236and host data descriptor lists 238 allows the local processor 222 to beabstracted to a higher level where it does not need to keep track of thehost address and byte count of data to be read or written.

The frame transmit engines 236 also utilize a free buffer pool 242,which contains pointers to free frame buffers 244 in the local memory226 that are capable of storing both the data and check bytes for asingle frame. The free buffer pool 242 helps each frame transmit engine236 fill up the local memory 226 when a new frame buffer 244 is needed.As the data expands, more frame buffers can be fetched to keep storingthe data. This frees the processor from having to calculate the exactmemory locations into which data will be stored, and when to switch to anew location. Note that in previous implementations, the buffers inlocal memory were managed by the local processor, and the allocation oflocations in memory for frame buffering was managed using a buffer poolwhich was in turn managed by the local processor. In embodiments of theinvention, the allocation of locations in local memory 226 for framebuffering is implemented in each frame transmit engine 236.

A protection information/scratch area 240 in RAM in the HBA 218 storesconfiguration information for each host data descriptor list 238, whichmay include the protection scheme (e.g. a cyclic redundancy check(CRC)), the size of the data unit (block size) to be protected by eachgroup of one or more check bytes generated in accordance with theprotection scheme, and the frame size (because different sequences andtargets may have different frame sizes). The protectioninformation/scratch area 240 may contain the same number of entries asthere are host data descriptor lists 238, one for each sequence offrames to be transmitted to a particular target 204. The protectioninformation/scratch area 240 may be utilized by the global DMA engine224 to determine the configuration information for the data to be reador written. The protection scheme may identify how check bytes are to begenerated and where they are to be inserted. Information identifyingmultiple protection schemes, including, but not limited to, the T10protection information standard, may be stored in the protectioninformation/scratch area 240. For example, embodiments of-the inventionmay support multiple check byte or DIF types, including standard DIFs(T10 DIFs), legacy DIFs (pre-standard customer formats), and proprietaryDIFs (customer-specific formats). In some instances, the configurationinformation may direct the DMA engine 224 to strip off some protectiondata, which may be needed when communicating with legacy targets thatare not able to handle check bytes.

The global DMA engine 224 may also utilize the protectioninformation/scratch area 240 as a scratch area because of the potentialindependence of size of the data being accessed from host memory and thesize of the frames to be transmitted. Because of these size differences,the data retrieved from host memory may not completely fill a framebuffer. In addition, because of the inserted check bytes, the dataretrieved from host memory may spill over into the next frame buffer.Thus, the protection information/scratch area 240 may store scratch areainformation such as the ending point of the data in a particular entry,thereby identifying the next location at which to write. To program theprotection information/scratch area 240, the firmware 234 determinesfrom the host command the protection scheme for the data to be read orwritten, and stores this information in the appropriate entry in theprotection information/scratch area.

The DMA engine 224 may be comprised of hardware, and operates under thecontrol of the frame transmit engines 236 to perform data transfers toand from the host memory 212 without intervention from the hostprocessor.

In the case of a write operation to write data to a target, anapplication running on the host computer 202 first sends a command tothe driver 216, indicating that a write operation for host data isrequested. The driver 216 then sends the write request over bus 220 tothe firmware 234 in the HBA 218. The firmware 234 then determines fromthe host processor 210 the host addresses at which the data resides andthe size of the data to be read from those addresses, and stores thisinformation into the host data descriptor list 238 associated with thetarget.

The appropriate frame transmit engine 236 is then initiated by thefirmware 234 to perform the autonomous mapping of protected data intoframes. The frame transmit engine 236 reads the appropriate host datadescriptor list 238 to determine the locations of the data to be readand the byte count. It issues command to let DMA engine 224, reads theinformation in the appropriate entry of the protectioninformation/scratch area 240 to determine the protection scheme for thatdata and the frame size to be filled, and determines one or more freeframe buffers from the transmit free buffer pool 242. Then the DMAengine 224 reads the appropriate data from host memory 212 in accordancewith each host descriptor issued by frame transmit engine 236, one at atime, calculate the check bytes, insert the check bytes in theappropriate places alongside the data (one ore more check bytes for eachprotected data unit), and store the data and check bytes into the freeframe buffers in local memory 226. As will be discussed in furtherdetail below, the frame transmit engine 236 also generates and storesthe header information for that frame into a separate area of localmemory, and then combines the header, data and check bytes fortransmission over the network. In other words, embodiments of theinvention allow information to be directly handed over to hardware forfurther processing instead of involving the processor 222.

In some cases, the target may impose a limit on the amount of data itcan receive in one burst (burst length). If the target specifies a burstlength, the burst length is translated to the host byte count by the DMAengine 224 and sent back to the frame transmit engine 236 underprotection mode, which then must take this limit into account whendetermining how much data and associated check bytes to transmit to thetarget.

In the case of a read operation (by the host), the same steps areperformed by the frame transmit engine 236 in the HBA 218 of the targetdevice 204. In this case, the roles of the host and target devices arereversed, and the frame transmit engine (in the target device 204) willtransmit data from the target to the host, just as it transmits datafrom host to target in the case of a write (of host data to targetdevice).

Accordingly, embodiments of the present invention provide severaladvantages to the system 200. By offloading the local processor 222 fromhaving to perform the tasks needed to process outgoing traffic, andraising the level of abstraction at which the processor operates foroutbound data streams, the mapping of protected data into frames can beperformed at speeds that allow for system data rates of 8 Gbits/sec ormore to be achieved. In addition, this significantly frees the processorto perform other tasks.

FIG. 3 illustrates an exemplary frame transmit engine 336 according toembodiments of the invention. As mentioned above, the frame transmitengine 336 may offload the local processor by performing functions inhardware that would otherwise have to be performed by the localprocessor, such as identification of the type of data protection,identifying the data to read from host memory in view of the type ofdata protection, and where the check bytes are to be placed in the localmemory 326 along with the actual data.

The frame transmit engine 300 includes a DMA state machine 344, a DMAcompletion frame builder 346, a frame completion state machine 348, andlink logic 354. All of these blocks may be implemented in hardware usingconventional logic structures well-understood by those skilled in theart. When so instructed by the local processor 322, the DMA statemachine 344 reads the appropriate host data descriptor list 338 todetermine the host addresses and byte count of application data to beread from, or written to, host memory 312, reads the configurationinformation and frame size from the protection informationcontext/scratch area 340, and identifies one or more free frame buffersfrom the free buffer pool 342. In the case of a write operation, the DMAstate machine 344 then triggers the DMA engine 324 to read the data fromhost memory 312, compute the check bytes, insert the check bytes intotheir proper order within the data, and store the data and check bytesin the free frame buffers in the local memory 326. Note that the checkbytes and real data to be stored may be larger or smaller than a framebuffer size, so more than one frame buffer may be needed.

Each time the data for a single frame has been successfully moved intothe local memory 326, the DMA engine 324 sends a message 352 to the DMAcompletion frame builder block 346 within the frame transmit engine 336.The DMA completion frame builder block 346 then generates a header forthe frame being built and sends a command to link logic 354 to store theheader in a separate memory 356 reserved for frame headers, and send outthe completed frame. Note that the location of the header in theseparate memory 356 is specified by the same pointer in the free bufferpool 342 that points to the location in local memory 326 at which thedata and check bytes are stored. Thus, the command includes the pointerspecifying where the header should be stored in separate memory 356. Itshould be understood that previously, the header for every frame wasgenerated by the local processor, but in embodiments of the invention,the processor is further abstracted and need not deal with headergeneration. After the header has been stored in local memory 356, thelink logic 354 uses the pointer to locate the header, data and checkbytes, assembles the complete frame, and sends the completed frame outover the link 308. A frame completion message 358 is then sent from thelink logic 354 to frame completion state machine 348.

Note that because a sequence may include multiple frames, the completionof a frame may not signify the end of the sequence. There are also anumber of conditions that can terminate a sequence, including completionof all frames, reaching the burst length limit, and the like. When theframe completion state machine 348 determines that a sequence has beenterminated, it sends a message 360 to a local processor completion RAM362, indicating that the sequence associated with the frame transmitengine 336 has been terminated. A separate location in the localprocessor completion RAM 362 is available to store sequence completionsfor each frame transmit engine 336. The local processor 322 maysubsequently read the local processor completion RAM 362 to determinethat the sequence has been terminated. When the termination of asequence is detected, the local processor 322 may perform severalactions, depending on why the sequence was terminated. If the sequencewas completed, the local processor 322 may report back to the hostdriver that the sequence has been completed. If the sequence wasterminated prior to completion, but more data needs to be sent, thelocal processor 322 may send a command back to the host, requesting moredata.

If an error is detected in the PCIe interface, memory, or link, theframe transmit engine 336 may allow all outstanding tasks to complete,put all buffers back into the free buffer pool, and issue a completionto the local processor, indicating that an error occurred. The actualsteps taken may depend on what stage the data transfer process is in atthe time of an error. For example, if a termination is issued, any datathat has been delivered to the local memory through a DMA process butnot sent out over the link may be prevented from being sent out, and thebuffers would be reset. However, if frames are already queued up, thoseframes may be sent out even though the sequence is being terminated.

If a certain number of frames have been sent out and a link error isgenerated from the link logic, the local processor may direct the frametransmit engine to continue to send out one or more frames. However,because the check bytes are a function of the data that came before, itmay not be possible to re-generate the check bytes. Therefore, inembodiments of the invention, a replay feature may be implemented inwhich the generation of the sequence is re-started from scratch, but thepreviously transmitted frames will be dropped, and only the subsequentframes will be transmitted.

In addition, while the frame transmit engine 336 is processing data, ifthe driver indicates that this processing should cease, the firmware canterminate the operation in a manner similar to the detection of anerror.

FIG. 4 illustrates another exemplary representation of a host computer402 according to embodiments of the invention. For simplicity, FIG. 4shows only a single host data descriptor list 438, a protectioninformation context/scratch area 440, frame memory 426 (local memory), ahost data block 412 (host memory), and a DMA engine 424 which includesan expansion/contraction adjustment functional block 448, a host dataframe segmentation functional block 450, and a DMA controller 452. Thehost data frame segmentation functional block 450 controls the accessingof frame buffers from the free buffer pool as frames are filled withreal data and check bytes.

The expansion/contraction adjustment functional block 448 performsseveral functions with regard to the processing of data when the targetsends a burst length message back to the frame transmit engine 436 topause the transmission of data. For example, the burst length istranslated into a frame count so that the transmission of frames can bepaused at the proper point in the sequence, and the amount of data to betransferred is determined given the number of DIFs that need to beinserted or deleted and the burst length.

FIG. 5 illustrates an exemplary expansion/contraction adjustment block548 according to embodiments of the invention. In order to offload theprocessor from having to calculate the expansion or contraction of thedata stream due to the addition or deletion of protection information,the hardware must make the necessary adjustments to processor programmedvalues. This is accomplished by keeping two counters. Counter 554 trackshow many DIFs will be added or subtracted from the data stream, andcounter 556 tracks how many protected blocks are contained in thestream. Once this is known, the proper number of DIFs can beadded/subtracted from the programmed value. This new value is used totrack the amount of host data plus DIFs that will finally end up in thetransmitted frames.

FIG. 6 illustrates an exemplary block diagram 600 of the DIFexpansion/contraction 602 and frame segmentation 604 functions accordingto embodiments of the invention. Each host descriptor in a hostdescriptor list can specify a certain amount (e.g. up to 16 Mbytes) ofdata. In the example of FIG. 6, 4 kbytes of host data is specified.After translation, the data specified by the host descriptors need tofurther be processed and segmented into frame size elements. The framesize is a variable supplied by the processor and can vary (e.g. 4 to 2Kbytes). A certain number of streams of data can be active at any giventime and each stream can have a unique frame size.

Although the present invention has been fully described in connectionwith embodiments thereof with reference to the accompanying drawings, itis to be noted that various changes and modifications will becomeapparent to those skilled in the art. Such changes and modifications areto be understood as being included within the scope of the presentinvention as defined by the appended claims.

1. An apparatus for transmitting host data to a target over aframe-based communications network, comprising: one or more frametransmit engines, each frame transmit engine configured for determiningone or more addresses, byte counts and a protection scheme of the hostdata to be transmitted in a particular sequence of frames, a frame sizeof the frames to be transmitted, and one or more free frame buffers forstoring the frames prior to transmission, generating and storing headersfor the frames to be transmitted, and combining the header information,data and check bytes into frames for transmission over the network; anda direct memory access (DMA) engine coupled to the one or more frametransmit engines and configured for reading the host data to betransmitted from host memory in accordance with the addresses and bytecounts determined by a particular frame transmit engine, calculatingcheck bytes for the host data in accordance with the protection scheme,and storing the data and check bytes into the one or more free framebuffers.
 2. The apparatus of claim 1, further comprising one or morehost data descriptor lists, each host data descriptor list accessible toa particular frame transmit engine for storing the addresses and bytecounts of the host data to be transmitted for a particular sequence. 3.The apparatus of claim 2, further comprising a protectioninformation/scratch area accessible to the one or more frame transmitengines for storing the frame size and protection scheme of the hostdata to be transmitted for one or more sequences.
 4. The apparatus ofclaim 3, further comprising a free buffer pool accessible to the one ormore frame transmit engines for identifying free frame buffers.
 5. Theapparatus of claim 1, further comprising a local processor configuredfor receiving a request from a host to transmit the host data to thetarget, determining the host addresses for the host data to betransmitted from the host and the byte count at those addresses, andstoring this information as host descriptor information into a host datadescriptor list.
 6. The apparatus of claim 1, further comprising a localprocessor configured for receiving a request from a host to transmit thehost data to the target, determining the frame size and the protectionscheme for the host data to be transmitted from the host, and storingthis information in a protection information/scratch area.
 7. Theapparatus of claim 3, each frame transmit engine comprising a DMA statemachine configured for reading an appropriate host data descriptor listto determine the addresses and byte count of the host data to betransmitted, and reading the protection information/scratch area todetermine the protection scheme and frame size of the host data orsingle host descriptor to be transmitted.
 8. The apparatus of claim 4,each frame transmit engine comprising a DMA completion frame builderconfigured for receiving a frame completion message from the DMA engineand generating a header for a frame to be transmitted.
 9. The apparatusof claim 8, each frame transmit engine comprising link logic configuredfor receiving a header from the DMA completion frame builder, storingthe header in at a location specified by a free frame buffer, using thefree frame buffer to locate the host data, check bytes and header,assembling a completed frame, and sending the completed frame out overthe network.
 10. The apparatus of claim 9, each frame transmit enginecomprising a frame completion state machine configured for receiving aframe completion message from the link logic and sending a message to alocal processor completion memory when the sequence of frames beinghandled by the frame transmit engine is to be terminated.
 11. A host busadapter (HBA) comprising the apparatus of claim
 1. 12. A host computercomprising the HBA of claim
 11. 13. A storage area network (SAN)comprising the host computer of claim
 12. 14. An apparatus fortransmitting host data to a target over a frame-based communicationsnetwork, comprising: a first memory area for storing addresses of hostdata and a byte count of the host data to be transmitted at thoseaddresses; a second memory area for storing a protection scheme and aframe size for the host data to be transmitted; and a frame transmitengine and a direct memory access (DMA) engine coupled to and configuredfor reading the first and second memory area, generating check bytes inaccordance with the protection scheme, generating one or more headers,and combining the headers, host data and check bytes into one or moreframes for transmission over the network without involvement by a localprocessor.
 15. The apparatus of claim 14, further comprising a thirdmemory area for storing the host data and check bytes, and a fourthmemory area for storing the one or more headers.
 16. An apparatus fortransmitting host data to a target over a frame-based communicationsnetwork, comprising: means for determining one or more addresses andbyte counts of the host data to be transmitted in a particular sequenceof frames, determining a protection scheme and a frame size of the hostdata to be transmitted in the particular sequence of frames, anddetermining one or more free frame buffers for storing the frames priorto transmission; means for reading the host data to be transmitted fromhost memory in accordance with the determined addresses and byte counts,calculating check bytes for the host data in accordance with theprotection scheme, and storing the data and check bytes into the one ormore free frame buffers; means for generating and storing headers forthe frames to be transmitted; and means for combining the headerinformation, data and check bytes into frames for transmission over thenetwork.
 17. A method for transmitting host data to a target over aframe-based communications network, comprising: determining one or moreaddresses and byte counts of the host data to be transmitted in aparticular sequence of frames, determining a protection scheme and aframe size of the host data to be transmitted in the particular sequenceof frames, and determining one or more free frame buffers for storingthe frames prior to transmission; reading the host data to betransmitted from host memory in accordance with the determined addressesand byte counts, calculating check bytes for the host data in accordancewith the protection scheme, and storing the data and check bytes intothe one or more free frame buffers; generating and storing headers forthe frames to be transmitted; and combining the header information, dataand check bytes into frames for transmission over the network; whereinthe method is performed without involvement by a local processor. 18.The method of claim 17, further comprising determining the addresses andbyte counts of the host data to be transmitted in the particularsequence of frames from a host data descriptor list.
 19. The method ofclaim 18, further comprising determining the protection scheme and theframe size of the host data to be transmitted in the particular sequenceof frames from a protection information/scratch area.
 20. The method ofclaim 19, further comprising determining the one or more free framebuffers for storing the frames prior to transmission from a free bufferpool.
 21. The method of claim 18, further comprising receiving a requestfrom a host to transmit the host data to the target, determining fromthe host the addresses for the host data and the byte count at thoseaddresses, and storing this information into the host data descriptorlist.
 22. The method of claim 19, further comprising receiving a requestfrom a host to transmit the host data to the target, determining theframe size and the protection scheme for the host data to betransmitted, and storing this information in the protectioninformation/scratch area.
 23. The method of claim 17, further comprisingsending a sequence termination message to a local processor completionmemory when the transmission of the sequence of frames is to beterminated.
 24. A method for transmitting host data to a target over aframe-based communications network, comprising: storing addresses ofhost data and a byte count of the host data to be transmitted at thoseaddresses into a first memory area; storing a protection scheme and aframe size for the host data to be transmitted into a second memoryarea; and reading the first and second memory area, generating checkbytes in accordance with the protection scheme, generating one or moreheaders, and combining the headers, host data and check bytes into oneor more frames for transmission over the network without involvement bya local processor.